Von Governance-Befunden zu Governance-Signalen

Der erste Beitrag dieser Reihe stellte die These auf, dass Governance ein Gedächtnis braucht. Die nächste Frage lautet, was dieses Gedächtnis speisen sollte und wann aus einer Beobachtung ein Signal wird.

Governance erzeugt an vielen Stellen Informationen. Linter melden Regelverstöße. Sicherheitsscanner identifizieren Schwachstellen. Architektur-Reviews dokumentieren Bedenken. Teams beantragen Ausnahmen. Reviewer genehmigen bestimmte Abweichungen und lehnen andere ab.

Diese Informationen verbleiben meist in dem Werkzeug oder Prozess, in dem sie entstanden sind. Ein Befund bleibt im Log einer Pipeline. Eine Review-Entscheidung liegt in einem Ticket. Die Begründung für eine Ausnahme ist nur einer kleinen Gruppe bekannt, bis sich deren Zusammensetzung ändert.

Befunde, Reviews, Ausnahmen und Begründungen müssen über ihre ursprünglichen Werkzeuge und Prozesse hinaus miteinander verbunden bleiben. Dafür braucht es eine Unterscheidung zwischen Beobachtungen und Signalen sowie zwischen technischer Evidenz und menschlicher Beurteilung.

Das Prinzip reicht über APIs hinaus

API-Design ist nur ein Anwendungsfall eines allgemeineren Prinzips. Thilo Rottach brachte diesen Gedanken in einem Kommentar zu meinem LinkedIn-Post über den ersten Artikel auf den Punkt.

Die gleichen Überlegungen gelten für statische Anwendungssicherheitstests, Security Code Reviews, Architektur-Reviews, Cloud Usage Reviews und andere Formen von Governance. In jedem dieser Fälle wird ein Ist-Zustand mit Regeln, Guardrails, Erwartungen oder professionellen Einschätzungen verglichen.

Diese Aktivitäten wiederholen sich. Dadurch sind sie mehr als eine Folge voneinander unabhängiger Kontrollen.

Ein einzelnes Architektur-Review kann auf ein lokales Problem hinweisen. Treten ähnliche Bedenken in mehreren Systemen auf, kann dies eine Schwäche der Plattform oder der zugrunde liegenden Architekturprinzipien sichtbar machen.

Eine einzelne Ausnahme kann in einem bestimmten Kontext nachvollziehbar sein. Eine wachsende Zahl ähnlicher Ausnahmen kann dagegen darauf hindeuten, dass die zugrunde liegende Regel nicht mehr zu den Systemen passt, für die sie gelten soll.

Wiederkehrende Reviews erzeugen deshalb nicht nur Evidenz über die betrachteten Systeme. Sie liefern auch Hinweise auf die Qualität und Wirksamkeit des Governance-Ansatzes selbst.

Von Lifecycle Intelligence zu Governance-Evidenz

Bereits 2018 beschäftigte ich mich unter dem Begriff Application Lifecycle Intelligence mit der Frage, wie sich Daten aus Versionsverwaltung, Continuous Integration, Issue Tracking, Deployment-Pipelines und Anwendungsmonitoring miteinander verbinden lassen.

Jedes dieser Systeme lieferte nur einen Ausschnitt des Software-Delivery-Prozesses. Ein umfassenderes Bild entstand erst durch die Verbindung und Interpretation ihrer Daten.

Governance steht vor einem ähnlichen Fragmentierungsproblem. Die Eingangsgrößen sind jedoch vielfältiger. Neben maschinell erzeugten Befunden gehören dazu Reviews, Ausnahmen, Begründungen und Entscheidungen.

Die Aufgabe besteht daher nicht nur darin, Daten zu aggregieren oder bessere Metriken zu berechnen. Governance muss auch nachvollziehbar machen, wie Evidenz interpretiert wurde.

Technische Sensoren und menschliche Beobachtungspunkte

Der Begriff Sensor ist hilfreich, weil er den Blick auf die Quellen richtet, aus denen Governance Informationen erhält. Er darf jedoch nicht den Eindruck vermitteln, alle relevanten Beobachtungen seien automatisiert oder objektiv.

Zu den technischen Sensoren gehören API-Linting, statische Anwendungssicherheitstests, Dependency Scanning, Policy as Code, Architecture Fitness Functions, Cloud Policy Checks, Laufzeittelemetrie und Audit-Ereignisse.

Sie liefern strukturierte und wiederholbare Evidenz. Ihr Aussagebereich wird jedoch durch Regeln, Schwellenwerte, Konfigurationen und die verfügbaren Daten bestimmt. Ein Linter bewertet eine API immer gegen ein bestimmtes Regelwerk. Ein Scanner meldet nur das, was seine Erkennungslogik identifizieren kann.

Governance ist deshalb ebenso auf menschliche Beobachtungspunkte angewiesen. Architektur-Reviews, Security Code Reviews, API-Design-Reviews, Risikobewertungen und Ausnahmeprozesse behandeln Situationen, die sich nicht vollständig in ausführbare Regeln übersetzen lassen.

Menschen können Kontext, Zielkonflikte und mögliche Folgen berücksichtigen. Ihre Einschätzungen sind zugleich von Erfahrung, Interpretation, organisatorischer Perspektive und dem zu diesem Zeitpunkt verfügbaren Wissen geprägt.

Beide Quellen sind notwendig. Sie repräsentieren jedoch nicht dieselbe Art von Evidenz.

Ein Scanner-Befund, ein Einwand aus einem Review und eine genehmigte Ausnahme haben unterschiedliche Bedeutungen. Ihre Herkunft, ihr Status und ihre Beziehungen müssen deshalb nachvollziehbar bleiben.

Jede Beobachtung sollte mindestens mit dem betrachteten Artefakt und seiner Version, dem anwendbaren Control und dessen Version sowie der Quelle der Beobachtung verbunden sein. Ebenso müssen das Review oder der Prozess, in dem sie bewertet wurde, die daraus entstandene Entscheidung und Begründung sowie spätere Korrekturen, Abläufe oder Ersetzungen erhalten bleiben.

Von der Beobachtung zum Signal

Eine Beobachtung hält fest, dass etwas aufgetreten ist. Ein Signal zeigt, dass diese Beobachtung über den Einzelfall hinaus Aufmerksamkeit verdient.

Häufigkeit allein reicht für diese Unterscheidung nicht aus.

Ein Namensverstoß in vielen API-Beschreibungen kann auf eine unklare Guideline oder ein fehlendes Template hindeuten. Ebenso gut kann es sich um eine weitgehend kosmetische Abweichung handeln, die keine größere Intervention rechtfertigt.

Ein einzelner Sicherheitsbefund kann wichtiger sein als Hunderte formaler Abweichungen, wenn seine möglichen Auswirkungen entsprechend schwerwiegend sind.

Wiederkehrende Ausnahmen können zeigen, dass eine Policy unrealistisch ist. Sie können aber auch darauf hinweisen, dass Teams gelernt haben, eine notwendige Kontrolle zu umgehen.

Ob aus einer Beobachtung ein Signal wird, hängt vom Kontext ab:

• Wiederholung über mehrere Teams oder Systeme hinweg

• Schweregrad und mögliche Auswirkungen

• zugrunde liegende Regel und deren Version

• wiederkehrende Entscheidungen in vergleichbaren Fällen

• Veränderungen im Ausnahmeverhalten

• Konzentration auf eine bestimmte Technologie oder Plattform

• Maßnahmen, die aus früheren Befunden entstanden sind

Nehmen wir zwei Teams, die gegen dieselbe Regel verstoßen. Bei einem Team kann die Ursache ein Missverständnis sein. Beim anderen fehlt möglicherweise eine notwendige Fähigkeit auf der gemeinsam genutzten Plattform. Der Befund sieht gleich aus. Die angemessene Reaktion ist dennoch eine andere. Governance Analytics darf deshalb nicht beim Zählen von Verstößen stehen bleiben. Beobachtungen müssen mit Entscheidungen und deren Folgen verbunden werden.

Ein erstes relationales Modell

Eine erste Umsetzung erfordert keine umfangreiche technische Plattform. Eine relationale Datenbank kann als Grundlage ausreichen. Ein mögliches Modell könnte folgende Entitäten enthalten:

• Artifact

• ArtifactVersion

• Control

• ControlVersion

• Observation

• ObservationSource

• Review

• Decision

• Exception

• Rationale

• FeedbackAction

Entscheidend ist die Trennung zwischen dem, was beobachtet wurde, der Art seiner Bewertung und den daraus entstandenen Konsequenzen. Werkzeugbefunde werden als Beobachtungen gespeichert. Reviews ergänzen den notwendigen Kontext und führen zu Entscheidungen, Ausnahmen oder Folgemaßnahmen. Diese können wiederum eine Regel, eine Plattformfähigkeit, ein Trainingsangebot, ein Template oder den Review-Prozess selbst verändern. Die Datenbank muss nicht zwingend physisch zentralisiert sein. Governance-Informationen können in unterschiedlichen Systemen verbleiben, solange gemeinsame Identifikatoren und Beziehungen eine Verbindung ermöglichen. Eine Organisation sollte den Weg von einer Beobachtung über die dadurch beeinflusste Entscheidung bis hin zur daraus entstandenen Maßnahme nachvollziehen können.

Den Feedback-Loop schließen

Der Wert dieses Gedächtnisses zeigt sich daran, ob die gespeicherte Evidenz künftige Regeln, Plattformen und Entscheidungen beeinflusst. Wiederkehrende Befunde können sichtbar machen, dass Regeln unklar, veraltet oder schwer anwendbar sind. Muster über mehrere Teams hinwegkönnen zeigen, wo Enablement erforderlich ist. Das betrifft nicht nur neue Kolleginnen und Kollegen. Auch erfahrene Fachleute arbeiten mit sich verändernden Plattformen, Standards und regulatorischen Anforderungen. Wiederholte Abweichungen können auf fehlende Plattformfähigkeiten hinweisen. In einem solchen Fall wird eine weitere Guideline wenig bewirken. Ein sicherer Standard, eine wiederverwendbare Komponente oder ein unterstützter Golden Path kann die wirksamere Antwort sein. Frühere Entscheidungen können zugleich dazu beitragen, künftige Reviews konsistenter zu gestalten. Vergleichbare Fälle werden sichtbar, Begründungen können hinterfragt werden und Governance hängt weniger vom persönlichen Gedächtnis einzelner Expertinnen und Experten ab. Keine dieser Reaktionen sollte automatisch aus einem Dashboard folgen. Ein Muster ist zunächst ein Anlass zur Untersuchung. Die passende Antwort kann eine geänderte Regel, eine Investition in die Plattform, gezieltes Enablement oder auch die bewusste Entscheidung sein, am bisherigen Vorgehen festzuhalten. Die entscheidende Frage lautet deshalb nicht länger, wie viele Befunde Governance produziert. Entscheidend ist, ob diese Befunde verändern, wie eine Organisation Regeln gestaltet, Teams unterstützt und ihre nächste Entscheidung trifft.